Hello! I'm running Vavoom on FreeBSD. I have it installed with the FreeBSD ports system. The first time I've installed it, it was version 1.24. Yesterday I've upgraded to 1.25 as it was merged to the ports tree after that it has been frozen for a while. After the upgrade I can't load my saved game anymore. As soon as I try to load a saved game Vavoom exits with the following messages No such class WeaponShotgun (running with -doom) No such class WeaponMissile (running with -doom2) No such class WeaponSuperShotgun (running with -plutonia) No such class WeaponSuperShotgun (running with -tnt) (I have no saved games for hexen, heretic and strife) Looking at the sources I've found that, for example, /vavoom-1.24/progs/doom/game1/WeaponShotgun.vc has been moved (?) to /vavoom-1.25/progs/doom/game1/Shotgun.vc and so on... Is the problem related to these changes? I've tried modifying the saved files with an hex editor (e.g. deleting 'Weapon' before 'Shotgun'), but it crashes with this error: terminate called after throwing an instance of 'VavoomError' Is there a way to fix my saved games?

As far as I know, there was this issue since early days of Vavoom. Also, about editing savegames - usually data files are not that easy to modify especially if you change their LENGTH (by adding or removing symbols), because most probably there are size values for whole file, strings, data chunks etc - written somewhere and if you change length of file you mess everything.

In these cases an import/export utility for savegames would be quite useful. Janis, what do you think about that?

I don't see an easy solution for this, since the game uses server/client architecture, if progs get things added these structures need to get the same additions for the game to be loaded, maybe there can be a way to determine what needs to be changed, but it would be difficult indeed.

Yes, savegames are not compatible between different versions of Vavoom. There are some ways how this could be improved.

Someone over in the zdoom forum made a decent suggestion concerning this. The idea is an alternate plain-text version-independent savegame format. It would only save upon entering a level or hub. Player's inventory, weapons, health, armor, ammo, etc would be stored, and that's all. This could be tied to an "autosave" routine that automatically saves one of these files whenever a player enters a level or hub, or triggered manually. These files could be loadable by the command line or console, and probably shouldn't show up as regular savegames (although they could). While this doesn't completely address the issue, I think it's a pretty good compromise - the player can at least start on the last level he was playing, with the inventory he had when he arrived there.